Software in Medical Devices, by MD101 Consulting

In the previous post, we've seen when it's mandatory to be compliant both with IEC 60601-1 and IEC 62304, and when IEC 60601-1 alone is enough.

But some manufacturers don't apply IEC 60601-1, mainly because their devices are not in contact with the patient or cannot be qualified are medical devices. We find in these categories in-vitro diagnosis instruments and laboratory instruments.
These instruments usually fall in the scope of IEC 61010-1. Let's see now the relationship between IEC 61010-1 and IEC 62304.

We've seen in the last post how to manage changes in legacy software. Let's see it from another point of view: the type of legacy software.

IEC 62304 requires to split architecture of class C (mission critical) software into software items and software units. Software units are software items that can't be split into sub-items, according to the standard. Okay. But how to decide that an item can't be split into sub-items, and is a unit?

In my previous post about Bugs, Software Risks and Software Failures, I explained the concepts of bugs, defects or anomalies, and the concept of software failure.
Let's continue now with Risks.

Are agile methods compatible with the constraints of development set by IEC 62304 standard of class C software?
After a series of three posts about agile methods and risks analysis. I focus in this post on IEC 62304 class C critical software.

This post is the continuation of the post of last week.
We've seen in that post that fixing bugs during software maintenance is like a small chunk of design, excepted that software specifications do not change. Therefore risk management process when fixing bugs is very close to risk management process during design, without the initial assessment of risks at the beginning of the software development cycle.

I didn't have time to post anything worth it this week.
To give a side view of my last post about software classes, here is a link to DO-178B on wikipedia. It is the reference about software embarked in aircrafts.
If you take time to read this document, you will see that it goes very further than what we have today in IEC 62304. The constraints about design on high classes are very very hard to respect. That's normal, when you think that software is used in flight commands and other stuff in the cockpit.
It has some side effects, mainly to stretch software development projects, and to ban software from some parts of the plane, for cost-driven reasons.
For example, a microcontroler plus software plus electric motors would be perfect to memorize and retreive the position settings of the pilot's seat. But the cost to develop such software is very high, as the pilot's seat is seen as a critical component. Aircraft manufacturers prefer replacing software and microcontroler by good old analogic electronics to do the same task on some models.
In my humble opinion, the constraints of the two highest classes for software in aircrafts would be to high for medical devices. There is always a pratician, or an emergency medical service, able to "catch" the patient if something goes wrong. Whereas there is nobody to "catch" a falling plane if its flight commands fail. The consequences of risks are far higher in aircrafts, with potentially hundreds of victims in an accident.
That is why classes A, B and C, and their design constraints are enough for medical devices.

Next week, I'll talk about exemptions of ISO13485 for standalone software medical devices.
Bye.

At last, here is the Risk Management Plan Template.

The risk management plan was missing in my list of templates. Error repaired! It is tailor made for software medical devices. So you'll find some stuff specific to software, with references to IEC/TR 80002-1 and IEC 62304.

The homologation of a medical device is a complex task and can become a nightmare with devices with a high level of risk. It involves many standards and regulations, different from one country to another: FDA in the USA, CE Mark in Europe, CMDCAS in Canada, KFDA in South Korea, and so on …

Fortunately, most of these regulations have common requirements and rely on ISO standards, the most important standards being ISO 13485 and ISO 14971. If you meet the requirements of these standards, you increase your chances of passing the homologations for the devices with low risk. For devices with high risk, these standards are (almost) mandatory.